[HTTPCLIENT-2381] Respect system properties by default#797
[HTTPCLIENT-2381] Respect system properties by default#797rschmitt merged 1 commit intoapache:masterfrom
Conversation
The practical effect of this change is that default JVM configuration for key stores (for mutual TLS) and proxy selection will be respected by default. This change has two goals. First, applications and libraries built on the client will work with proxies much more reliably, since their authors no longer need to opt in to a non-default setting in order for things like proxies to be configurable in the usual manner (i.e. without code changes). Second, this change, along with the change in 5.6 to make `BUILTIN` the default `HostnameVerificationPolicy`, makes the client's configuration philosophy fully consistent across all supported features. To wit: 1. HttpComponents _itself_ is always configured programmatically and does not directly read system properties to obtain config values. 2. For a given feature, the default behavior is to delegate to the JDK implementation. This implementation may support out-of-band configuration via system properties, static methods, the `java.security` file, system-wide OS configuration, etc. 3. This delegation behavior can be overridden by a programmatic config option, either to directly customize the JDK-supplied implementation or to supply an alternate implementation. This table shows what this philosophy looks like concretely across various features: | Feature | Default JDK behavior | Example JDK config property | Override strategy | | --------------------- | ---------------------------------------------- | --------------------------- | ------------------------------------------------------------------------------- | | Trust store | Load from OS | `javax.net.ssl.trustStore` | Set a `TrustManager[]` | | Key store | Load nothing | `javax.net.ssl.keyStore` | Set a `KeyManager[]` | | Hostname verification | Run `HostnameChecker` from `sun.security.util` | None | Set a `HostnameVerifier` and `HostnameVerificationPolicy` | | Proxy config | Use system properties or load from OS | `java.net.useSystemProxies` | Set a `ProxySelector` or `HttpRoutePlanner` | | Client cipher suites | Send all supported cipher suites | `java.security.properties` | Set an `SSLContext` | | IP family selection | Prefer IPv6 | `java.net.preferIPv4Stack` | Set a `DetachedSocketFactory` or `DnsResolver`, call `setUnixDomainSocket`, etc | | DNS resolution | Use built-in resolver | `networkaddress.cache.ttl` | Set a `DnsResolver` | See also the previous discussion at: apache#773
|
When we upgrade |
|
Thanks !
Maybe all this (and more options ? can you make it more secure (tied to user, not all tcp of localhost) ? socks (never used it)?) should go into some guide, otherwise I'm pretty sure people are going to be pretty confused (especially with the removal of the support for -DproxyUser -DproxyPass) Thanks again for taking the time to work on this, |
The practical effect of this change is that default JVM configuration for key stores (for mutual TLS) and proxy selection will be respected by default. This change has two goals.
First, applications and libraries built on the client will work with proxies much more reliably, since their authors no longer need to opt in to a non-default setting in order for things like proxies to be configurable in the usual manner (i.e. without code changes).
Second, this change, along with the change in 5.6 to make
BUILTINthe defaultHostnameVerificationPolicy, makes the client's configuration philosophy fully consistent across all supported features. To wit:java.securityfile, system-wide OS configuration, etc.This table shows what this philosophy looks like concretely across various features:
javax.net.ssl.trustStoreTrustManager[]javax.net.ssl.keyStoreKeyManager[]HostnameCheckerfromsun.security.utilHostnameVerifierandHostnameVerificationPolicyjava.net.useSystemProxiesProxySelectororHttpRoutePlannerjava.security.propertiesSSLContextjava.net.preferIPv4StackDetachedSocketFactoryorDnsResolver, callsetUnixDomainSocket, etcnetworkaddress.cache.ttlDnsResolverSee also the previous discussion at:
#773